Computer memory is often allocated among multiple memory pools. Memory pools include portions or ranges of memory. A portion or range of memory is often referred to as a “block” of memory. Blocks of memory from different pools are used to satisfy different classes of memory allocation requests. The size of each of the memory pools is typically controlled by and managed through use of separate memory parameters.
With some approaches to memory management, a management system may specify static default values for the sizes of each memory pool based on certain heuristics. For example, a system may have a static default value that specifies that 20% of the available total shared memory should be allocated to memory pool X, and another static default value that specifies that 30% of the available total shared memory should be allocated to memory pool Y. Such values are considered “static” in that they do no change during operation of the system, and any change too them only takes effect after restarting the system.
With other approaches to memory management, a system administrator is responsible for manually sizing memory pools. Any attempt to optimize such sizing typically involves an iterative process of trial and error, and is a difficult task because the different memory pools are used for different purposes. Manual sizing of memory is particularly difficult because what the best allocation of memory for a system under some conditions may be different than the best allocation of memory for the same system under other conditions.
For example, assume that a database server employs a first pool for use when performing backup jobs, and a second pool used for on-line transaction processing (OLTP) activities. If a large amount of memory is allocated to the first pool and a smaller amount to the second pool, then nightly recovery management backup jobs may go smoothly, but daily OLTP activity will suffer. On the other hand, if a large amount of memory is allocated to the second pool, and a smaller amount to the first pool, backup jobs may fail, or may not be completed because the first pool is set too small. The cost of backup failures could be prohibitive from a business point of view, leaving administrators with few other options.
In practice, the memory allocation parameters of a system are rarely adjusted after an administrator sets (“tunes”) the memory allocation parameters for a given application or cluster of applications. Failure to adjust the parameters to account for changes causes problems, since undersized pools could lead (1) to application failures due to failure to allocate sufficient memory to given pools, and (2) to performance problems arising from the need to reload data or perform excessive disk I/O. Hence, memory pool allocations are commonly oversized to handle the worst-case scenarios while attempting to avoid system errors, and with the goal of avoiding the need for reallocation. For example, some types of pools are often oversized to prevent application errors, at detriment to the performance of other memory pools. Oversizing memory pools also usually leads to wasted system memory resources.